え、そんなに！？意外と知らないAWSでお金がかかるポイント5選！！第2弾

「でかいインスタンスを建てればAWSの料金が高くなっていく…。」
「大量購入すればお金が飛んでいく…。」

こんにちは(U・ω・U)
AWS事業部の深澤です。

さて僕はこの前このような記事を公開させていただきました。

お陰様でご好評でしたので、今回はその続編で料金に注意が必要なAWSリソースをピックアップしました。どうぞ最後までお楽しみいただけると幸いです。では最初に注意事項を申し上げておきたいと思います。

注意

• 今回ご紹介するものは実際に検証したものではありません。AWSの料金表を確認して、実際このくらい溶けるのではと計算した理論値になります。
• 日本円のレートは執筆時現在（2020/1/23）のレートとなります。
• リージョンは東京です。
• それぞれがどういったサービスなのか、細かい話は割愛します。
• ここで取り上げたサービスが高いとか悪いとかそういうことを言いたいブログではありません。やはりサービスなので使い方によってはコストダウンになります。そのサービスを利用することによってかかるコストと削減できるコストの費用対効果をよく検討してからサービスをご利用ください。
• 本ブログの検証は大変危険です。よくお財布を確認してから検証してください。

サービス5選

NatGateway

まずご紹介させていただくのはこのNatGatewayです。皆さん、大変よく利用されるサービスかと思いますが時間単位で課金されていくというのはご存知でしょうか。実際どのくらいかかるか試算してみましょう。以下に1台あたりの費用を記載します。

1時間ごとにかかる料金	通信したGB単位の価格
0.062USD	0.062USD

この金額、冷静に計算してみましょう。1時間ごとに0.062USDなので1日辺り1.488USD（163.09円）です。これが1ヶ月稼働し続けたと考えて44.64USD（4892.66円）です。またNatGatewayでは複数AZで運用する場合、可用性担保のため同じく複数AZで運用することが推奨されています。なので44.64 * 運用するAZです。最低でも89.28USD（9785.31円）となり、大凡1万円が1ヶ月で溶ける試算となります。これに上乗せで先ほどの通信費がかかってきます。さらにNatGatewayは停止が行えず、削除するしか方法がありません。EIPは残すことができるのでIP制限されている環境への接続に影響が出ることはないですが、通信頻度が少ない場合にこの金額（大凡1万円）は結構痛いと感じられる方もいらっしゃるのではないでしょうか。

もしNatGatewayの金額にお悩みの方がいらっしゃいましたら、以下の方法をご検討いただくといいかもしれません。WEBアプリケーションサーバとかDBサーバの場合、必ずしも常にインターネットに繋がっていなくてはならないというケースも珍しいかと思いますので。

• 定期的にNatGatewayの削除と作成を自動で行うBatchを作成する
• 冗長化は諦めてシングルAZにする
• 必要な資源（パッケージ）はローカルからSSH等で送る
• 必要な資源（パッケージ）はS3に配置して、VPCエンドポイント経由で取得するようにする

EIP

続いてご紹介するのはEC2インスタンス等に付与するEIPです。こちらのEIP、ざっくりと「アタッチされていなければ課金対象」と思われている方も多いのではないでしょうか。これは間違いではないのですが、実はEIPの課金パターンはそれだけではありません。まず最初に無料になる条件を申し上げますと、稼働しているインスタンスにアタッチされており、かつそのインスタンスにはEIPが1つしかアタッチされていない場合にEIPは無料です。「アタッチされていなければ課金対象」なのは勿論、1つのインスタンスに対して複数のEIPを付けた場合も課金対象です。ここでEIPは1つ辺り0.005USD（0.55円）が1時間毎に課金されていきます。1日で0.12USD（13.15円）、1ヶ月で約3.6USD（394.57円）。これが複数になったらその分課金されていきます。

EC2の場合は、削除する際にEIPを解放するかを聞いてくれます。
しかし、このEIPはNatgatewayにも紐付きます。そしてNatgatewayでは削除する際、このように解放するか聞いてくれません。ここは注意ポイントですね。

また、EIPはそれ以外にも料金が発生するポイントがあります。インスタンスにEIPを外して他のインスタンスに関連付ける（リマップ）を100回以上繰り返すと1回毎に0.1USD（10.96円）発生します。仮に1000回やれば90USD（9864.23円）のお金が溶ける可能性があります。shellとかでスクリプト組めば一瞬で溶かせそうですね。

この辺りについては弊社の渡辺聖剛の記事が非常に参考になります。

対策ですが、AWS Configのマネージドルールであるeip-attachedを導入することを推奨します。

こちらを導入しAWS Configからの通知で空いているEIPの検知が楽になります。上記ドキュメントにも書かれていますが評価の結果が出るまでは最大 6 時間かかることがあるのでその点だけ注意です。

Amazon S3

AWSの提供されているサービスの中で最も使われていると言っても過言ではないこのS3ですが、様々な料金プランが存在することをご存知でしょうか。主要なプランをピックアップしてざっくりとまとめてみます。

S3のタイプ	特徴
標準	一般的に使われるタイプ
低頻度アクセス	標準と同じ可用性だが標準と比べて通信費が高くストレージ料金が安い
低頻度アクセス 1ゾーン	標準と比べて通信費も安く、ストレージ料金も低頻度アクセスより安いが1AZにしか保存されないため可用性が低い
Glacier	データがアーカイブされるため取り出しに時間がかかる、ストレージ料金が上記に比べて安いが取り出しの際に通信費と別途取り出しの料金が発生する

それぞれの細かいコストについては以下を参照ください。

このようにS3のプランによってそれぞれ得意なことが違い、正しく使えば料金を下げることに繋がるのですが一歩間違うと逆に高コストになりかねません。例えば、標準と低頻度アクセスではリクエスト系の料金に次のような違いがあります。

プラン	PUT、COPY、POST、LIST リクエスト (1,000 リクエストあたり)	GET、SELECT、他のすべてのリクエスト (1,000 リクエストあたり)
標準	0.0047USD	0.00037USD（0.041円）
低頻度アクセス	0.01USD	0.001USD（0.11円）

全然アクセスしないと思ってプランを低頻度アクセスに切り替えたけど、実は標準並にアクセスがきちゃったなんて日には標準の2倍ちかいリクエスト料金が発生します。S3は実際のワークロードに応じて適切なプランで検討することが重要です。

Amazon Transcribe

さてここまでメジャーなサービスできましたがちょっと毛色の違うサービスをピックアップしてみました。こちらは音声をテキストに文字起こししてくれるサービスです。こちらは1秒あたり0.0004USD（0.044円）のお金が溶けます。1分間で0.024USD（2.63円）1時間で1.44USD（157.83円）です。実はコンソールから行うとS3に配置してある音声ファイルからしかロードしてくれないのですが、音声録音に対応したアプリがあるんです。

こちらのサービスで気をつけたいのが秒数の課金ということです。変換した文字数ではないので、うっかり付けっぱなしにしてうたた寝してしまった暁には真っ白なテキストとうたた寝した時間分の請求が出来上がってしまうでしょう。

DynamoDB

さて続いてはDynamoDBの料金です。DynamoDBの料金はフルマネージドでサーバレスが故にちょっと特殊ですよね。DynamoDBではインスタンスが存在しないので、どのくらいDynamoDBを使ったかというスループットキャパシティ単位で料金が決まります。読み込みをRCU（Read Capacity Unit）と呼び、書き込みをWRC（Write Capacity Unit）と呼びます。それぞれのCapacity Unitの内訳は次のようになっています。

• 読み込み（4KB につき）
  • 強力な整合性のある読み込み
    • ユニット数：1
  • 結果整合性のある読み込み
    • ユニット数：0.5
  • トランザクション読み込み
    • ユニット数：2
• 書き込み（1KB につき）
  • 標準の書き込み
    • ユニット数：1
  • トランザクション書き込み
    • ユニット数：2

今回ご紹介するのはグローバルセカンダリインデックスに対する処理を行った場合です。グローバルセカンダリインデックスについての説明は今回割愛させていただきますので詳しく知りたい方は以下の公式ドキュメントをご参照下さい。

さて、先ほどのスループットキャパシティ単位（キャパシティユニット）で料金が発生するという話ですが、これはテーブル単位だけで発生する話ではありません。グローバルセカンダリインデックスを用いてインデックスを付与した場合、そのインデックスに対する更新、読み取りでもキャパシティユニットが発生します。ここで更に注意したいのが書き込み処理を行った場合です。読み込み処理の場合、その対象となるインデックスやテーブルだけにRCUが使われますが、書き込み処理を行った場合その結果がインデックスにも反映されるためテーブル及び全てのインデックスにWCUが発生します。「ちょっとしか更新していないはずなんだけどWCUで物凄いお金溶けてるんですけど…」という時には是非この話を思い出して、CloudwatchメトリクスのConsumedWriteCapacityUnitsを確認しましょう！

ちなみに意外と知られてませんが、コンソール画面でテーブルの内容を確認しただけでも読み込みの項目をクリックしただけでもRCUを消費します。 「あれ、そういえばテーブルってどんな感じになってたっけな〜」と軽い気持ちでクリックするとユニット数分のお金が溶けて、最悪RCUが不足している場合にはサービスに影響が出るので注意しましょう。

最後に

いかがでしたでしょうか！今回は割と皆さん利用されるのではというサービスをピックアップしてみました。なのでAWSを普段からよく使っていますよと言う方にとってはお馴染みだよねという方も少なからずいらっしゃったかと思います。やっぱりこれだけのサービスをこの価格で提供できるAWSはすごいです。これらを自前で実装して可用性も担保するとなるとここで紹介したような金額では済まないですからね…。

また、請求が来てから気づくのではなく、監視しておいて早めに異変を検知できるようにしておきたいですよね！いくつか参考になりそうな弊社ブログをピックアップしましたので良かったら参考にしてみて下さいm(_ _)m
AWSサービス毎の請求額を毎日Slackに通知してみた
支払アカウントからリンクアカウントのBilling Alertを設定する

以上、深澤（@shun_quartet）でした！